Org Design in the Age of AI

来源：Freda Duan (@FredaDuan), 2026-04-12 (212 likes)

最新验证 (2026-04-28)

• PM-工程师融合 — 吴恩达与 Anthropic 共识：最快团队让工程师即产品经理
• 罗福莉谈 OpenClaw — Agent 框架中间层可以很厚，前端 UI 成为最薄的一层

核心观点

AI 正在改变工作方式，但大多数公司只是在现有工作流中添加 AI，而没有重新思考工作流本身的合理性。

三个核心变化

1. 中层管理压缩 (Middle Management Compression)

翻译成本趋近于零

• 想法 → 执行的转换摩擦大幅降低
• PM 从"翻译想法给工程师"转向"直接验证"
• 幸存者不是自动化任务的人，而是完全消除交接的人

"The translation cost framing is the part most people miss. Everyone's measuring AI by whether it makes a task faster. It gets interesting when it removes the task entirely because the handoff it served no longer exists." — Kevin Bray

2. 职能边界模糊 (Blurring Functional Boundaries)

跨职能能力民主化

• 设计师可以直接生成代码
• 工程师可以直接产出设计
• 传统"转交"模式的价值被削弱

新的协作模式

• 端到端所有权 (end-to-end ownership)
• 一人 + Agents 替代传统团队协作

3. 风险与所有权重新分配

企业风险吸收机制改变

• 传统：分层审批分散风险
• AI 时代：快速验证替代层层把关
• 100% AI 组织的出现可能只是时间问题

批评与反思

反面观点

"PMs become builders. Less time translating ideas for others, more time validating directly." — No. It's replacing a process (even a bad one) with a tool. Stakeholders are ignored. Total collapse of cross functional working. Zero risk mitigation. PMs doing everyone else's work. — UXer_Alex Tamayo

关键问题

1. 跨职能协作崩溃风险 — 用工具替代流程可能破坏必要的协调
2. 利益相关者被忽视 — 快速验证不等于全面考虑
3. 风险缓解缺失 — 传统流程存在的理由可能被低估

如何应用

• 审视当前工作流中哪些步骤是为了"交接"而存在
• 评估哪些中层协调工作可以被 AI 替代 vs 必须保留
• 重新定义角色边界（工程师 vs 设计师 vs PM）
• 建立 AI 时代的协作规范
• 设计新的风险缓解机制

关联

• product-trends/ai-era-pm-playbook — AI 时代 PM 新打法
• product-trends/ai-pm-onboarding — AI PM Onboarding
• forecasts/post-labor-economics — 后劳动经济框架
• harness-engineering/copilot-vs-delegate — 同步 vs 异步协作

企业 AI 落地的残酷现实：70–80% 项目困在试点阶段（2026-05-03）

来源：The Rundown 2026-05-03 UiPath CMO Interview

UiPath CMO Michael Atalla 在 IPO 五周年之际分享了企业 AI 落地的真实图景：

从 automate the task 到 orchestrate the workflow

五年前 UiPath 的卖点是"自动化任务，解放人力"。如今客户的问题已从"能不能自动化这个？"变成了"怎么让这些东西协同工作？"——数十个自动化流程并行运行，却彼此孤立，无法连接到企业的实际业务目标。

唯一没有变的赌注：技术应该消除人们工作中的摩擦，而不是增加新的摩擦。

70–80% 的 agentic AI 项目从未走出试点阶段

Atalla 直言，AI 试点几乎总是在孤立环境中运行：一个 agent 在业务的一个角落，一个自动化在另一个角落，彼此之间没有可见性。试点成功了，领导层问"下一步呢？"，却没人能给出真正的答案。

"突破这一阶段的组织并没有做什么激进的事。他们只是停止把 AI agent 当作要部署的工具，开始把它们当作更大、受治理的工作流的组成部分。"

近半数组织称 AI 是'巨大失望'——尽管投入巨大。真正的问题在于协调：工具已经部署，但没有连接到企业真正想实现的目标。ROI 就在这个缺口中消失了。

AI 就业焦虑：角色在改变形状，而非消失

• 四分之三的 AI 专家对 AI 就业影响持乐观态度，但只有 23% 的公众认同
• 自 2024 年以来，入门级开发岗位下降近 20%，而高级岗位却在增长
• 新的岗位正在围绕工作流设计、AI 治理和端到端流程所有权涌现

"我女儿 13 岁。五年后她申请大学时，她要竞争的工作可能还没有被命名。"

UiPath 内部的人机协作模型

• 自动化：处理结构化、可重复的部分——拉取数据、匹配记录、路由请求
• Agent：在有模糊性时介入——标记异常、解释不符合标准模板的发票
• 人类：审查例外情况，做出真正需要判断的决策——审批、升级、任何有后果的事情

Atalla 认为"完全自主"的对话远远跑在了实际发生的前面。近景模型是：agent 在编排好的工作流内运行，承担更多认知责任，但仍受治理、仍可观察。

Slock.ai：7 人 + 40 Agent 的组织实验（2026-05-03）

来源：<a href="/wiki/raw/to-learn/agent动力学：这家公司把自己"运行"在自己的产品上-->-slock的设计哲学和使用经验.md" class="wikilink">Agent动力学 — Slock 设计哲学

Slock 创始人 RC 的团队配比是 7 个人加 40 个 Agent。这个配比不是设计出来的，是演化出来的：从 1 人 + 1 Agent 开始，逐渐发现需要多个 Agent 并行处理不同任务。

Agent 分工：大量工程师（不细分前后端）、一个工程师主管（关注其他 Agent 的进展并给出总结报告）、designer、growth、strategy 等角色。

任务认领：RC 在频道里发任务，Agent 自行 claim。它们会因为做过某类事情而更倾向于继续做—— emergent specialization。

与 Snap 设计团队的对比：

• Snap：9-12 人设计团队，无层级，靠 Spiegel 每周投入几小时维持创新
• Slock：40 个 Agent，人类只负责发任务和选择方向，Agent 自行协调执行
• 两者都验证了"小团队/高自主性"模型，但 Slock 把自主性下放给了 Agent

Coding vs Building 正交：RC 的核心观察。以前想 build 必须 code，所以 builder = coder。现在 coding agent 足够发达，没有编程基础的人也能 build。这对组织设计意味着：招聘标准从"会写代码"转向"能定义目标、能验证结果"。

Jaya Gupta：公司形态本身就是护城河（2026-05-11）

来源：AI时代最宽的护城河 — Jaya Gupta

Foundation Capital 合伙人 Jaya Gupta 的核心判断：当模型快速改进、界面趋同、产品迭代速度变得廉价时，公司本身的组织形态才是真正的护城河——而不是产品、技术或赛道。

伟大的公司是组织上的发明

最重要的公司实际上是组织形式上的发明。它们围绕一种新的工作类型创造出一种新的机构，并在此过程中让一种新型的人成为可能：

• OpenAI 不像学术界也不像传统企业——它把训练前沿模型放在引力中心，安全、政策、产品、基础设施全部围着这个核心转
• Palantir 为失灵的系统发明了一种新的运营型机构——前向部署不只是市场进入动作，而是一种地位层级、人才模型和世界观

顶尖人才竞争的是身份认同

最优秀的公司竞争的不只是品类、市场或薪酬，它们竞争的是身份认同。有抱负的人渴望：

情绪承诺必须是结构承诺

如果公司说客户亲近是护城河，但面向客户的工作地位低下，承诺就是假的。说所有权重要但决策权集中，也是假的。

被选中和被看见是两回事

• 被选中是情绪层面的：你很特别、你属于这里
• 被看见是结构层面的：这是你的 scope、权限、经济参与、决策权

最危险的承诺是以"时间"计价："以后会做大的""结构以后会跟上"。但时间不会在它溜走时提醒你。

对创始人的问题

真正的问题不是"如何讲更好的故事"，而是：什么样的人只有在这里才能成为真正的自己？

对求职者的启示

你押的是一个具体的人的愿景，和一个具体的组织形状。招聘流程在揭示这两件事上出奇地不靠谱——它给你看的是话术、使命、想象中的未来，但极少展示真实的权力结构，几乎从不展示这群人在压力下的样子。

与 Org Design 主题的整合

Jaya Gupta 的框架将 Org Design 的讨论从"职能边界如何调整"提升到"组织形态如何成为不可复制的资产"。这与本文前面讨论的：

• 中层管理压缩 → 小形态里一个人真能改变轨迹
• 职能边界模糊 → 新型的人无法被清晰归入传统分类
• 风险重新分配 → 结构承诺必须跟上情绪承诺

形成同一条线：AI 时代的组织设计，核心问题不是效率，而是形态。

Snap 的双组织模型（2026-04 案例补充）

来源：Lenny's Podcast 对谈 Evan Spiegel

Spiegel 引用了 Safi Bahcall 的书 《Loonshots》：一家公司需要同时拥有两种团队才能在大规模交付的同时保持创新。

两种组织

关键洞察

两种团队之间的张力是天然的——小团队嫌大团队官僚，大团队嫌小团队不务正业。领导者的核心工作不是偏向其中一种，而是维护两种组织之间的对话和相互尊重。

Snap 的实践

设计团队：长期保持在 9-12 人，无职级、无头衔层级。任何人可以把任何想法带到每周设计评审会。入职第一天就要展示作品。Spiegel 每周花几小时跟设计团队一起看新作品，每周看到上百个新想法。

PM 角色：Snap 在员工超 200 人后才招第一个产品经理。Spiegel 的担忧是传统 PM 会让设计师沦为"接到需求出视觉稿"的角色。早期态度："如果你觉得需要 PM 支持，自己做那份工作。"

上线瓶颈：设计团队至今是产品上线的瓶颈环节——这是刻意的设计，保证了用户体验的连贯性。

AI 改变内部工作方式：

• 设计师开始直接提交代码（AI 辅助）
• 自动代码审查系统已检出近万 bug
• "摇一摇手机报 bug"→ AI Agent 自动诊断修复
• go-to-market Agent：输入产品想法 → 自动输出产品规格文档 + 风险分析 + 营销材料

与本文的对应关系

Snap 的实践证明：

1. 中层管理压缩 → 设计团队无层级，PM 延迟引入
2. 职能边界模糊 → 设计师提交代码，Agent 替代协调角色
3. 风险重新分配 → 自动代码审查 + AI Agent 诊断替代传统审批流程

Agent Manager 角色与 Claude Code 企业落地（2026-05-14）

来源：Anthropic — How Claude Code works in large codebases

Anthropic 官方提出大型组织中 Claude Code 落地的组织层配套：

Agent Manager：一个混合 PM/工程师职能的角色，专门管理 Claude Code 生态。

• 拥有 CLAUDE.md 层级、插件市场、权限设置和 skills 上线的决策权
• 负责保持配置随模型进化而更新（建议每 3-6 个月做一次有意义的配置审查）
• 回应企业推广中"模型变好但 setup 不跟进、没有人 ownership"的普遍瓶颈

最小可行版本：一个 DRI（直接负责人），拥有配置所有权、权限策略调用权和 CLAUDE.md 约定维护责任。

最快的推广模式：

• 在广泛开放前投入基础设施：一个小团队（甚至一个人）先把插件和 MCP 搭好
• 开发者的第一次体验必须是高效的而非挫败的
• 自下而上的热情需要有人把有效的做法集中化和传播，否则知识停留在部落层面，采用率会停滞

治理问题需早期解决：

• 谁控制哪些 skills 和 plugins 可用
• 如何防止数千工程师独立重复造轮子
• AI 生成代码如何经过与人类代码相同的 review 流程
• 建议从已批准的 skills 集合、强制代码 review 流程和有限初始访问开始，随信心增长逐步扩展

Fiona Fung：AI 时代的工程团队管理（2026-05-12）

来源：Fiona Fung — Code with Claude 2026 演讲

Fiona Fung（Anthropic Claude Code & Cowork 工程与产品负责人，前 Meta/微软）在 Code with Claude 2026 大会上分享了 Claude Code 团队过去一年的管理实践。核心判断：编码不再是瓶颈，验证、评审、协作和安全才是。

正在失效的旧流程

因为"开发成本太高"而被历史倒逼出来的流程，在 AI 时代正在失去杠杆：

• 六个月路线图 → 原型成本趋零，"提前规划"的杠杆消失。Fiona 用 jit planning（即时规划）替代
• 设计文档先行 → 默认讨论媒介从"先写 doc"换成"先发 PR"，有想法直接做出来
• 产品评审会 → 产品形态变化太快，不如推给全员 ant-fooding（内部 dogfood）再推给用户
• 站会/周进度表 → 信息已在 Claude 能读到的地方，让 Claude 写总结脚本，随时拉状态摘要

验证左移（Shift Left）

传统 QA 接不住暴增的代码产出率，质量保障必须更早依赖自动化：

• 风格检查、lint、常规 bug、单元测试 → 交给 Claude
• 法律合规、安全边界、产品品味（sense）→ 保留人工

Fiona 的品味例子：圣诞节想让 Claude 画 ASCII 雪人，设计师说"你把它画成了 Mr. Peanut"——抽象判断很难自动化。

技术辩论：从白板到三个 PR

有分歧时，让 Claude 同时搓出三个版本的 PR，直接对比完整实现和全局影响。白板上画不出的视角，代码可以。

当写代码变得轻而易举，无休止的争论就显得极其昂贵。

底线共识反而更关键：决不能沦为"谁最后一个 commit 谁赢"。

组织形态：扁平 + 经理从 IC 做起

• Claude Code 和 Cowork 两条线只共用一个 team mission，不让小组各自定 mission（多层级对齐太耗时）
• 所有经理先做 IC，不接受就分开。Fiona 自己 2017 年后首次 push 代码到生产
• 招聘看两类人：有产品感觉的创意建造者 + 深度系统专家。不再看重原始编码吞吐量

代码作为唯一事实来源（Source of Truth）

技术客诉的答复方式：启动 Claude Code，挂载 repo，让模型直接从代码找逻辑回答。开发文档与代码不同步的千年问题被干掉。

三个还没答案的问题

1. 工程师跨平台流转后，iOS/Android 分队还有没有意义？
2. 自动化评审要推到多远？"信任但验证"的边界随模型升级移动
3. 角色模糊后，怎样让所有人感觉同样有产出感？

Input, Output, Outcome：AI 生产力的正确衡量框架（2026-05-12）

来源：The layoffs will continue till we learn to use AI — Arnav Gupta (@championswimmer)

AI 生产力讨论常陷入"AI 是否让我们更高效"的循环争论。一个更清晰的分析框架区分三个层级：

核心洞察

Code is input. Features are output. Users spending money is outcome.

AI 编码工具（如 Claude Code）按 input 定价：生成 100M tokens/天/工程师 = 约 $100/天 = $30k/年。这笔支出相当于 0.25-1 个工程师的薪资，取决于地区。如果 AI 增加的 input 成本无法转化为同比例的 outcome 增长，裁员就成为平衡资产负债表的算术必然。

两个被揭示的组织问题

1. 坏想法的过滤机制失效 过去" coding 耗时"天然过滤了 80% 的 CEO/PM 脑暴。现在 coding 免费，坏想法也能快速变成 MVP，导致资源分散在无法产生 outcome 的方向上。

2. 对齐成本暴露 过去 coding 速度隐藏了组织对齐的摩擦。现在两个团队可以各花一夜用 AI 做出 MVP，但基于不同假设。对齐会议没有减少，只是从"能不能做"变成了"为什么你做的跟我不一样"。

对 AI 裁员潮的解释

这些裁员不是 because AI 直接替代了 30% 的员工，而是 because：

• AI 支出需要被 offset：token 消耗是真实成本，在 outcome 未跟上的情况下，只能通过削减工资支出来平衡
• 减少对齐税：10-20% 的裁员在短期内反而可能加速决策，因为需要对齐的人少了

结论：裁员会继续，直到我们学会将 AI tokens 转化为 outcomes，而不仅仅是 inputs。

AppLovin 的 AI Native 组织极端实践（2026-05-20）

来源：AI Agent 时代的工作革命 — 十期播客精华综述 — Adam Foroughi, AppLovin CEO (20VC)

AppLovin 市值 1500 亿美元，核心业务 400 人，人均 EBITDA 接近 1000 万美元。其组织设计代表 AI Native 的极端形态：

组织精简哲学

• 没有产品团队 — "工程师本来就应该是产品经理"
• 没有 CRO、COO、CMO、CHRO — "只要我身边都是高产出的实干者"
• 不做一对一会议、不做绩效评审 — "优秀的人不需要手把手的照顾"

AI 采用策略

• 80-90% 的代码是 AI 生成的（但强调质量比数量重要）
• "如果你激励的是垃圾产出，那作为一家公司你走不了多远"
• 部署 Agent 大军前必须清楚交付物是什么，以及它是否对应业务增长
• "你在 token 上的投入能不能被这些代码贡献所创造的收入覆盖"

裁员逻辑

在三位数增长的年份仍然裁员 40-50%：

• "如果一个岗位将来会被自动化，或者采用 AI 的速度不够快，那就该让这些人离开"
• "我们不想承担另一种风险：把人继续留在死胡同一样的岗位里"
• "假设我们今天从零开始搭建公司，并且知道现在有哪些技术可用，那我们的文化和组织会长什么样？"

Token 预算观

• "如果你只是给大家一个预算，再做一个 token 使用排行榜，人们会造出一堆没有价值的垃圾"
• "公司需要先搞清楚自己到底在优化什么"
• "token 预算和招聘指标没有区别——在他们变得高效之前，他们都会低效"

Dan Shipper：Cloud Code 与工作方式预测（2026-05-20）

来源：AI Agent 时代的工作革命 — 十期播客精华综述 — Dan Shipper, Every CEO (Lenny's Podcast)

超级 Agent 模式

• 公司内部会有一个全公司共用的超级 Agent（如 Shopify 的 Sidekick、Ramp 的 Agent）
• 每个 Agent 都需要一个"在乎它的人"来维护——需要像打理花园一样打理 Agent
• 从顶层通用 Agent 开始，逐渐下沉到专门的团队 Agent
• 主要发生在 Slack 里，而非个人设备上

Codex / Claude Code 成为工作操作系统

• 你做的所有工作都会发生在 Codex 或 Claude Code 这类环境里
• 内置浏览器是关键创新——Agent 能看到你正在做的一切
• SaaS 工具将运行在 Agent 里面，而非 Agent 内置到 SaaS 里
• 用户自带 AI（BYOAI），SaaS 公司不需要为 token 付费

关键判断

• "CLI 时代已经结束了"——GUI 工作更舒适，Agent 在旁边一起运行
• "SaaS 末日论很蠢"——Agent 增加 SaaS 用户数量，而非消灭 SaaS
• "两个 Agent 比一个更好"——Agent 之间的交互能提供远超人类能表达的上下文
• "每一个 Agent 都需要一个人"——自动化是谎言，维护成本被低估

人才预测

• PM 和全栈设计师将过得很好
• PM 需要变成"能定义目标、能验证结果"的人
• 设计师可以直接生成代码，不再需要交接
• "你唯一需要做的就是 ride the models"

Compute Allocator：产品经理的新角色（2026-05-20）

来源：AI Agent 时代的工作革命 — 十期播客精华综述 — Clara Vo & Tharikshi, Anthropic (How I AI)

当 Agent 运行时间从几分钟变成几小时，产品经理的新角色是算力分配者（Compute Allocator）：

• "当你说 Claude 可以跑八个小时，真正的意思是 Claude 可以花掉大概五百美元"
• 决定哪些事情值得把算力花上去
• 计划、PRD、spec 仍然重要，因为它们是算力投资的决策依据

这一角色将 PM 从"写 PRD 等工程师实现"转向"决定算力预算的 ROI"。详见 Compute Allocator。

Sundar Pichai：Google 的 AI 战略判断（2026-05-20）

来源：AI Agent 时代的工作革命 — 十期播客精华综述 — Sundar Pichai, Google CEO (Hard Fork)

关键判断

• "Coding 最终会成为我们所做一切的基础"
• Google 在 Agent Coding 和指令遵循长周期任务上"有点落后"
• "30 到 60 天看起来就像五年"
• AGI 更可能偏近（3-5 年）而不是偏远（5-10 年）

AI 就业观

• "人类并不是为了处理这么多变化而进化出来的"
• "如果人们没有更加焦虑，我反而会惊讶"
• 医生可以用 AI 把更多时间花在病人身上
• 放射科医生的扫描量和信息量十年内还会再变十倍

Agent 信任

• "你必须让用户有一种感觉，就像当年我们要让一个人坐进自动驾驶汽车的后座一样"
• "如果发生了意料之外的事，用户会退回去，不再使用"

职级设计的信号功能：MTS 的扁平化智慧（2026-05-24）

来源：AI 简报 2026-05-24 Evening — Yuchenj_UW thread (4,837 likes)

MTS（Member of Technical Staff）的设计精妙之处

MTS 是一个精妙的职级设计：它过滤掉了 title-maxxer，保护工程师免受 corporate ladder 思维侵蚀，同时让招聘方无法仅凭 LinkedIn 判断级别。

三个核心效果

1. 消除层级攀比 — 统一的 MTS title 消除了 Staff/Principal 等层级带来的攀比和内耗
2. 减少 title 偏见 — 招聘方看到 MTS 时无法判断是 L4 还是 L7，减少了"以 title 取人"的偏见
3. 聚焦技术本身 — 让工程师专注于技术本身，而非爬梯子

与 Org Design 主题的整合

MTS 设计呼应了本文前面讨论的组织形态变化：

• 中层管理压缩 → 扁平 title 消除了"向上爬"的结构性激励
• 职能边界模糊 → 当工程师同时做 PM、设计和架构工作时，单一 title 反而更准确
• 风险与所有权重新分配 → 减少 title 竞争意味着更多能量流向实际产出

这与 Snap 设计团队"无职级、无头衔层级"的实践（见上文）形成跨案例验证：AI 时代的组织设计，正在从"层级激励"转向"任务激励"。

如何应用

• 在团队或公司设计职级体系时，参考 MTS 的扁平化思路，减少层级带来的摩擦
• 招聘时不过度依赖候选人的 title，而是通过实际技术对话评估能力

Anthropic 内部协作全景：流程被压缩进可执行系统（2026-05-30）

来源：傅里叶 — Anthropic 团队是怎么协作和运转的？

基于 Anthropic 官方 PDF、Claude Code 团队访谈及 Mike Krieger、Joel Lewenstein、Cat Wu 等公开分享的系统整理。

核心反常识：Anthropic 不是"低流程"，而是把流程变成了可执行代码

外部观察常误以为 Anthropic "没什么流程"——工程师看到用户反馈当周就能上线，设计师也可以直接改代码。但把官方资料放在一起看，画面几乎相反：

• 会议没有消失，只是被压缩了
• PRD 没有消失，只是变薄了，但验收变厚了
• Code review 没有消失，而是变成了 AI 先做、人再做的双层结构

真正值得学的不是"低流程"这个口号（那是结果），而是如何把流程改造成一个可执行、可审查、可回滚、可验证的系统。

协作：当 builder 就是 user，反馈不需要翻译

Anthropic 的结构性优势是构建者本身就是目标用户。这形成了一条极短的信号链路：Twitter 抱怨 → 工程师自己也被烦到 → Claude Code 读代码、生成计划、改 diff、跑测试、开 PR → Code Review agents 并行扫一遍 → 人类 reviewer 看一眼 → 合并 → 进入下一轮内部 dogfooding。

跨职能 pod 才是真正的组织单位。设计负责人 Joel Lewenstein 强调：每个小型 pod 里都有设计、PM 和工程，而不是让设计师站在流程末端作为服务角色接收请求。

工程：从"写代码"变成"决定做什么、怎么验证"

公开资料能比较完整还原的前半段流程：

1. 保持 clean git baseline
2. 装载上下文（让 Claude 读仓库、CLAUDE.md 和历史实现）
3. 先要计划，不要直接改
4. 分层授权（视觉 polish 放得更开；核心逻辑、安全必须同步监督）
5. 用 checkpoint 控制风险
6. 跑测试，并追问失败原因

Evals 是发布门槛，不是奢侈品。 Cat Wu 的立场：先用 10 个高质量真实场景建立基本回归能力，不要等到有完美评估系统以后才开始。

产品：能力剧本，而不是多年路线图

Anthropic 发现产品机会同时看两条线：

• 用户线：开发者摩擦、API 客户真实任务、内部 dogfooding、社区反馈
• 模型线：新模型是否具备更强的 coding、agentic behavior、tool use、long context

Mike Krieger：产品团队嵌入研究团队，和 post-training、fine-tuning 一起工作，比只在模型外层做 UI 更有价值。

Joel Lewenstein 的 "football playbook" 概念：团队准备一组候选打法，当新模型能力、用户反馈或技术条件出现时，就快速选择合适的 play 执行。不是不要战略，而是把战略从"固定路线图"换成了"能力触发型剧本"。

发布级别：Internal → Labs → Research Preview → Beta → GA

这套机制让团队可以先发布、先验证，再逐步升级承诺，而不是被完美主义挡在 GA 门口。

设计：真实环境优先，设计师直接改代码

Anthropic 的设计交付不再只是一套高保真稿，而是一组东西：Figma + 可运行原型 + 状态流 + 边界情况清单 + 代码 diff + PR + 用户研究记录 + eval 场景。

设计师可以直接进代码改文案、间距、边界状态，但第 7 步仍由工程师把关：架构、状态管理、安全、可维护性。

速度边界：为什么别人不能照搬

Anthropic 的快速模式依赖六个特殊结构：

1. builder = user，反馈翻译成本接近零
2. Claude Code 全链路把定位、计划、实现、测试、PR、review、文档生成压进一个工作流
3. 设计师可以直接进代码，砍掉交接成本
4. PM 嵌在研究和工程旁边，围绕模型能力定义机会
5. research preview / Labs 降低了早期发布承诺
6. Evals + Code Review 让快速迭代不完全依赖主观判断

对于不控制模型的公司、用户和构建者差距很大的公司、销售和合规链条更长的 B2B 公司，直接照搬"工程师看到反馈就当周上线"是要出事的。

与 Org Design 主题的整合

Anthropic 的案例将前面讨论的三个核心变化推向极端：

• 中层管理压缩 → 提出需求的人、做实现的人、使用产品的人往往是同一个人
• 职能边界模糊 → 设计师直接提交代码，PM 嵌入研究-工程核心
• 风险与所有权重新分配 → 双层 Code Review（AI 先扫、人后看）+ 五级发布承诺替代传统审批链

这验证了 Jaya Gupta 的判断：组织形态本身就是护城河。Anthropic 的速度不是来自某一个技巧，而是六个机制叠加出来的结果。